\section{Analysis}
In this section, we discuss properties of \name, evaluate its efficiency and usability, and discuss other concerns

\subsection{Properties}
The \name protocol inherits many properties from the Mixcoin system. Below, we outline the properties of both systems and discuss any changes that occur due to our modifications.
%
\subsubsection{Accountable.} This propery is inherited from Mixcoin. In our modifications, we ensure that this property is preserved. 

We define \emph{mix accountability} to be the property that if the mix deviates from the protocol, their cheating can be provably exposed. A mix can deviate from the protocol and steal the user's funds, but the user can then publish their mix-signed warranty along with other evidence to show that the mix has cheated. A mix can steal user funds at several points in the protocol, but at each point the user is "protected" by their warranty. 

The warranty is slightly more complex in \name than in Mixcoin. When the mix agrees to a user's (blinded) offer, they issue a partial warranty back to the user, which is an agreement saying "if the user pays, the mix will publish the signed blinded token to the public log." The mix waits to publish the token to the public log is so that it can make sure that only valid, paid-for tokens are in the log. The reason that the token must be published to the log is so that third party verifiers can check that the mix has acknowledged a user's payment. As described in Sect. \ref{subsec:protocol}, if a mix does not publish signed blinded token to the public log before the agreed-upon deadline, the user can present proof of misconduct, which would be damaging to the reputation of the mix.

Another point in time that the mix could potentially cheat is when determining which output addresses to send funds to. If users have correctly followed the protocol and published their signed, unblinded tokens to the public log, then any party can see that the mix has signed the token. Furthermore, after the mix computes \crsrandfunc to determine the random collection of fees, it is possible for any party to verify that it has correctly computed the function, since \crsrandfunc is public. If the mix fails to transfer funds to an output address that has passed \crsrandfunc, then the user can again present proof of misconduct.
%
\subsubsection{Anonymous.} Mixcoin provides strong anonymity guarantees for its users except for the case in which the mix is the adversary. If a mix stores records, they could potentially release them to deanonymize users. In \name, we extend the many of the guarantees provided by Mixcoin and show that anonymity is possible even against a malicious mix. As in the Mixcoin protocol, we assume than an adversarywishes to link an output address \outaddr to the corresponding input address \inaddr.

The first adversarial model we consider is that of a \emph{global passive adversary}. Since the Bitcoin block chain is public and anyone can access all Bitcoin transactions (and to the public log in \name), this is the weakest adversary model that we consider. Both Mixcoin and \name provide guarantees that no global passive adversary can link input/output address pairs within a particular mix. A user's anonymity set consists of all users participating in the mix.
One property that Mixcoin provides is \emph{mix indistinguishability}. This property extends a user's anonymity set against a global passive adversary to \emph{all} users participating in mixes with the same mix data (see Sect. \ref{subsec:protocol} for a description of the mix data). Unfortunately, this does not hold for \name. To unblind their output address, a user publishes their signed token to the public log. This allows an adversary to link the output address \outaddr to the signing key of the mix \mixprivkey. 

A second adversarial model is one of an active attacker who is able to compromise some subset of the input/output address pairs for a particular mixing operation. In this model, the mix indistinguishability property of Mixcoin can be broken. However for both Mixcoin and \name, the anonymity set for a user remains the number of non-compromised address pairs.

We also consider the model where the mix is the adversary. This could occur if a mix is compromised or coerced into revealing its records. In the case of Mixcoin, all input/output mappings are revealed, since the mix has access to this information. This problem can be alleviated if the user sends their coins through multiple independent mixes, but a strong adversary could potentially compromise all of them. However, a compromised mix does not weaken the anonymity guarantees for \name. Mixes are blinded to the mapping from input to output addresses through the use of the blinded token scheme. This is the main contribution of \name.

In this analysis, we do not consider side channel attacks. For example, if the user interacts with the mix or the public log in a predictable manner, timing information may allow deanonyization. These side channel attacks are outside the scope of this paper.

\subsubsection{Resilient to Misbehaving Users.} This property is inherited from Mixcoin. As discussed above, 

\subsubsection{Scalable.} This property is inherited from Mixcoin.

\subsubsection{Incentivized.} Both users and mixes are incentized to participate in the system. For a small fee, users are able to safely mix their bitcoins. As always, there is a tradeoff between privacy and efficiency. Although there is some delay associated with a mixing operation in \name, the fact that one does not need to trust any party clearly makes this a valuable tool.
Mix servers are also incentivized. The fees collected by the mix are sufficient to cover %\TODO
\subsubsection{Compatible with Existing Protocol.} \name does not require any changes to the existing Bitcoin protocol, so it can be easily deployed.

\subsection{Security}
The mix must be the party that defines the {\sl mix data}. The reason for this is so that each user participating in the mix will have the same values for these parameters. Otherwise, if the user had to define these values, the mix could easily link together a single user's input and output addresses by looking at the values used.

\subsubsection{Mix accountability} If a mix deviates from the protocol, the wronged party can present a proof to any third party that the mix did not follow the protocol. If a dishonest mix steals coins, it will quickly have its reputation destroyed. A mix can deviate from the protocol in the following ways:
\begin{itemize}
\item If $M$ fails to publish $A$'s token by \warrantydeadline, $A$ can publish information to incriminate $M$ publicly. \item If \user fails to publish the unblinded signature to the public log by time \unblinddeadline, \mix can choose to either refund the coins back to \user or retain them. Since \user breached the protocol, it cannot produce evidence to incriminate $M$, so $M$ can do as it pleases with the funds.
\item \end{itemize}
\subsubsection{User accountability} If a user wishes to incriminate a mix, they must publish otherwise private information as proof that the mix deviated from the protocol. It is easy to verify whether or not a claim is valid, based on information present in the public log. \\

%
The times $(t_1, t_2, t_3, t_4)$ must be agreed upon by all mix participants and the protocol steps should be carried out within the appropriate time intervals. This will help to prevent timing analysis attacks in which a single user's interactions with the mix are all clustered together in a short period of time. Furthermore, users should not make their interactions with the mix predictable. For example, if the mix reveals a particular token and then an output address is unblinded immediately afterwards, the mix may be able to link the token to the output address.

\begin{itemize}
\item \emph{Accountable}. A user should be able to have a guarantee that their coins will not be stolen during the exchange process.
\item \emph{Anonymous}. The addresses a user provides for inputs to the mix should not be linkable to the addresses that the user provides for their outputs by any other party.
\item \emph{Resilient}. The system should not be vulnerable to attacks by a small number of malicious parties that could potentially DoS the exchange \cite{coinjoin},\cite{multiparty}.
\item \emph{Scalable}. The system should be able to scale to accomidate for large anonymity sets.
\item \emph{Incentivized}. There should be a mechanism for the mix to collect mixing fees fairly that will incentivize it to provide the service.
\item \emph{Compatible}. The system should be compatible with the current Bitcoin system.
\end{itemize}
